A general overview of group D's thoughts of the documentation and each of its chapters.

\section{Summary}

The document present the information through a professional structure that is easily read. Everything elicitated through the means of the primary questions in the interview are correct and correctly presented to the reader. There are general problems with grammar, spelling, lack of specification, tasks and confusion. At least the confusion and misunderstanding of the project were presented as a lack of communication between the requirement specification group and the consultancy group D, which we in group D agree as there has been no requested communication with us except a quick group interview which was held early in project.

\section{Background}

We do not understand the point of discussing public domain in the background. We also would like to see a more throughout discussion here.

\section{Context diagram}

If ``...'' means that there are more interactions betwene the system and actors, then we would liked to have those specified. If it doesn't mean that there are more interactions involved, then we would like to have a more specified solution. We do not understand the division of test suites, repository and program.

\section{General goals}

We do not see any main problems with the general goals and think it's quite well written. Maybe add here that we requested a very quick presentation of information while we suggested that the computation could be done when the program started.

\section{Text based use cases}

We would like to see more use cases than one. Also if there are to exist any use cases said use case should be better described.

\section{Design meeting}

Group B's project mission?

\section{Event list}

Events should maybe not have R as ID?
It gets confusing when both requirements and events have the identifying letter R.

\section{Interview}

The interview does well present the primary questions asked by group B to group D. It did miss the follow up questions. We explicitly asked for a solution which didn't have to use a server so we don't see how that requirement was elicitated here?

\section{Prioritisation}

Shouldn't the customer prioritize the requirements? How did group B estimate cost and benefit for each requirement?

\section{Stakeholder analysis}

We explicitly asked that group B would be a inhouse team. Which other tools did you speak of and how would they be able to be combined?

\section{Costs}

We do not see how said estimations could've been concluded. Hard costs and benefits seem to be taken out of the air without anything backing it up? Also as the development of said tool has already been decided the costs compared to total income of the company wouldn't be of any importance as said analysis has already been made.

\section{Requirements}

A lot of the requirement lack, or has a very limited, specification. We like requirement 8.2 as it was what we had in mind during the group interview. Requirements of the server and ticket tracking hasn't been mentioned by us and we do not see how they could've been elicitated for this project as they are not compatible with the product. A few requirements are mentioned in the text though are not a mentioned amongst the list of requirements.

\section{General}

There are grammatic and spelling errors throughout the document. There is often a lack of tracing of what actually has happened or how things were estimated. A lot of problems could've been solved by asking group D instead of guessing. In general we think the document is a good start. If group B put out a lot of work and a lot of communication with group D we can see that this requirement documentation might become a good document which could be used by us for the project's creation.